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REASONING  IN  MODEL  MANAGEMENT  SYSTEMS 

ABSTRACT 

Reasoning  is  crucial  to  successful  development  of  knowledge- 
based  model  management  systems.   It  is  particularly  important 
when  model  integration  is  needed  in  a  large-scale  system.   In 
this  case,  heuristics  must  be  used  to  reduce  the  complexity  of 
model  integration.   This  paper  discusses  the  issues  involved  in 
the  reasoning  process.   First,  a  hierarchy  of  abstractions  that 
integrates  previous  contributions  in  model  management  is 
presented.   Then,  the  modeling  process  is  formulated  as  a 
planning  process  by  which  a  set  of  operators  are  scheduled  to 
achieve  a  specified  goal.   This  process  involves  searches  for 
alternatives  that  can  eliminate  the  difference  between  the 
initial  state  and  the  goal  state.   Various  reasoning  strategies 
and  heuristic  evaluation  functions  that  can  be  used  to  improve 
the  efficiency  of  model  integration  are  discussed. 
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INTRODUCTION 


A  model  management  system  (MMS)  is  a  software  system  that 
handles  all  accesses  to  the  decision  models  stored  in  a  model 
base.   Its  primary  purpose  is  to  enhance  decision  performance  by 
providing  decision  makers  with  proper  models.   In  order  to 
achieve  this  goal,  functions  that  support  model  creation, 
storage,  retrieval,  execution,  and  explanation  are  essential. 
Among  them,  model  creation  is  the  most  knowledge-intensive 
function.   It  needs  knowledge  of  both  individual  models  and  the 
modeling  process. 

There  are  two  approaches  for  an  MMS  to  support  model 
creation:  user-assisted  modeling  and  automatic  modeling.   User- 
assisted  modeling  allows  a  decision  maker  to  specify  how  several 
smaller  models  can  be  combined  to  become  a  larger  one.   The  user 
is  responsible  for  finding  a  set  of  appropriate  models  and 
determining  the  best  way  to  integrate  them.   The  MMS  serves  as  a 
blackboard  on  which  the  user  examines  different  alternatives. 
Because  the  system  performs  a  limited  amount  of  intellectual 
activities  in  this  case,  its  implementation  is  easier  compared  to 
automatic  modeling.   In  general,  a  good  model  manipulation 
language  is  adequate. 

Instead  of  having  the  user  tell  the  system  what  to  do  and 
how  to  do  it,  automatic  modeling  requires  that  the  system 
automatically  formulate  a  decision  model  for  the  user.   A  long- 
term  goal  for  automatic  modeling  is  to  develop  an  MMS  capable  of 
designing  decision  models  based  on  the  problem  description 
provided  by  the  decision  maker.   This  would  allow  the  system  to 
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replace  human  model  builders.   Given  current  information 
technology,  however,  this  goal  is,  at  least  in  the  near  future, 
very  difficult  to  achieve.   One  major  difficulty  is  that  a 
modeling  process  usually  involves  a  huge  amount  of  common  sense  -■ 
a  set  of  knowledge  computers  cannot  yet  handle. 

At  present  a  feasible  goal  for  automatic  modeling  is  to 
develop  a  system  that  can  automatically  find  a  model  or  a 
sequence  of  models  already  stored  in  the  model  base  to  produce 
the  desired  information.   In  many  situations,  a  complex  model  is 
an  appropriate  integration  of  several  basic  models.   Given  a 
particular  problem,  therefore,  a  good  MMS  must  be  able  to  help 
the  user  locate  and  combine  the  relevant  basic  models  in  the 
model  base.   This  process  is  called  model  integration  [Liang, 
1986] .   The  model  base  provides  basic  components  for  modeling  and 
sets  up  a  knowledge  boundary,  which  allow  effective  use  of  the 
stored  models  without  incurring  the  difficulty  of  common  sense 
reasoning. 

Developing  the  model  integration  capability  needs  both  model 
representation  schemes  that  logically  represent  each  model  in  the 
model  base  and  reasoning  mechanisms  that  schedule  models.   In 
recent  years,  several  model  representation  schemes  have  been 
developed,  such  as  relational  [Blanning,  1982-1986],  logic-based 
[Bonczek,  Holsapple  &  Whinston,  1981;  Dutta  &  Basu,  1984; 
Kimbrough,  1986;  Pan,  Pick  &  Whinston,  1986],  frame-based  [Dolk  & 
Konsynski,  1982-1986],  and  graph-based  approaches  [Elam, 
Henderson  &  Miller,  1980;  Geoffrion,  1985-87;  Liang,  1986-1987]. 
However,  research  in  the  reasoning  side  is  far  behind.   Although 
the  formalisms  underlying  those  representation  schemes  may 
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provide  basic  reasoning  capabilities,  they  are  not  tailored  to 
the  need  of  model  management.   For  example,  a  logic-based  system 
can  prove  that  a  model  exists,  but  its  dependence  on  an 
exhaustive  search  may  dramatically  reduce  its  applicability  to 
many  problems.   Therefore,  unless  an  efficient  reasoning 
mechanism  for  model  management  is  developed,  providing  model 
integration  support  in  MMSs  would  be  very  difficult. 

In  this  article,  reasoning  issues  involved  in  the  model 
integration  process  are  discussed  from  a  planning  perspective. 
Most  problem  solving  processes,  as  stated  by  Simon  (1981,1983), 
can  be  considered  as  planning  processes  by  which  a  set  of 
operators  can  be  found  and  scheduled  to  eliminate  the  difference 
between  the  initial  state  and  the  goal  state.   This  process 
involves  search  with  the  presence  of  subgoals,  operators,  macro- 
operators,  and  abstraction.   Since  a  model  integration  process  is 
part  of  the  problem  solving  process,  it  can  be  analogously 
defined  as  a  process  by  which  available  models  are  selected  and 
scheduled  to  eliminate  the  difference  between  the  desired 
information  and  the  available  information.   In  order  to  determine 
and  eliminate  the  difference,  the  following  issues  are  crucial: 

(1)  State  representation:  what  information  should  be 
included  in  a  state  representation? 

(2)  Reasoning:  what  mechanisms  can  be  used  to  eliminate  the 
difference  between  the  goal  state  and  the  initial  state? 

(3)  Heuristic  functions:  how  can  the  efficiency  of  the  process 
be  improved? 

In  the  remainder  of  the  article,  they  will  be  discussed  by  this 

sequence. 
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HIERARCHY  OF  ABSTRACTIONS: 
A  REVIEW  OF  MODEL  REPRESENTATION 


To  determine  how  a  state  should  be  represented  one  must  first 
consider  what  level  of  abstraction  one  needs.   Here  the  concept  of 
abstraction  is  very  important.   In  order  to  efficiently  solve  a 
complex  problem,  a  problem  solver  must  first  ignore  low  level 
details  and  concentrate  on  the  essential  features  of  the  problem. 
The  details  are  filled  after  the  problem  has  been  solved  at  the 
higher  level.   Therefore,  abstraction  formation  involves  loss  of 
content,  which  makes  the  abstraction  simpler  than  its 
instantiation (s)  [Darden,  1987,  Korf,  1987].   This  idea  has  been 
used  for  problem  solving  for  a  long  time  [Poya,  1957]  and  adopted 
by  several  general-purpose  problem  solving  programs,  including 
General  Problem  Solver  (GPS)  [Newell  and  Simon,  1972]  and  ABSTRIP 
[Sacerdoti,  1974]. 

In  the  model  management  arena,  Dolk  and  Konsynski  (1984) 
first  adopted  the  term  "abstraction"  and  presented  a  model 
abstraction  technique.   In  fact,  despite  grounding  on  different 
formalisms,  most  model  representation  schemes  presented  in 
previous  research  reflect  different  levels  of  model  abstraction, 
from  user-oriented  to  execution-oriented.   For  example,  Blanning 
(1982-86)  emphasizes  the  manipulation  of  data  relations  (data 
level) ;  Liang  (1985-87)  focuses  on  the  mapping  between  inputs  and 
outputs  (model  level) ;  Geoff rion  (1985-87)  presents  a 
hierarchical  framework  for  structured  modeling  (structure  level) ; 
and  Dolk  and  Konsynski  (1982-86)  concentrate  on  model 
specification  (specification  level) .   Figure  1  illustrates  these 
five  levels  of  abstraction  for  the  EOQ  model  that  calculates 
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economic  order  quantity  from  demand,  holding  cost,  and  ordering 
cost. 


INSERT  FIGURE  1 


1.  Program  level 

At  the  bottom  of  the  hierarchy  is  a  Pascal  implementation  of 
the  EOQ  model.   This  reflects  a  highly  machine-oriented  view  of 
decision  models.   The  advantage  of  this  representation  is  that 
the  model  can  be  stored  in  a  model  base  and  be  readily  integrated 
and  compiled  for  execution.   Its  major  disadvantage,  however,  is 
that  little  information  relevant  to  model  management  is  provided. 
For  example,  it  provides  little  input  and  output  information  and 
can  be  activated  by  model  name  only. 

2 .  Specification  level 

By  ignoring  some  implementation  details,  Dolk  and  Konsynski 
(1984)  developed  a  frame-based  model  abstraction  technique.   This 
technique  represents  models  by  their  data  objects,  procedures, 
and  assertions,  all  expressed  in  first  order  predicate  logic.   An 
abstraction  for  the  EOQ  model  is  shown  at  the  specification  level 
in  Figure  1. 

The  contents  lost  at  this  level  of  abstraction  are 
implementation  details  and  direct  computer  executability . 
However,  it  gains  computer  language  independence.   The  same 
specification  may  have  interfaces  to  programs  in  different 
computer  languages.   An  early  work  conducted  by  Elam,  Henderson, 
and  Miller  (1980)  also  represented  models  at  a  similar  level  of 
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abstraction  but  in  a  graphical  form.   They  adopted  the  concept 
of  Si-nets  in  artificial  intelligence. 

Although  this  level  of  model  abstraction  may  be  useful  to 
model  builders,  it  still  includes  too  much  detail  for  most  users 
In  addition,  some  low  level  operations  such  as  checking  data 
formats  may  substantially  increase  the  complexity  of  model 
integration.   These  operations  need  not  to  be  considered  until  a 
set  of  potential  model  combinations  has  been  identified. 
Therefore,  further  abstracting  is  desirable. 
3 .  Structure  level 

Geoffrion's  framework  for  structured  modeling  further 
eliminates  some  integrity  constraints  and  data  formats.   It 
portrays  the  fundamental  structure  of  a  model  by  its  elemental 
structure,  generic  structure,  and  modular  structure. 

One  feature  of  the  structured  modeling  is  the  use  of 
graphical  symbols  rather  than  text-based  specifications,  which 
makes  the  functional  relationships  among  various  modules  very 
clear.   In  Geoffrion's  framework,  nodes  stand  for  modeling 
elements  and  arcs  stand  for  calls.   A  modular  structure  of  the 
EOQ  model,  as  shown  in  Figure  1,  contains  four  nodes  and  three 
arcs. 

A  graph-based  model  structure  provides  certain  insight  into 
a  model.   For  the  purpose  of  model  integration,  however, 
representing  the  detailed  structure  may  not  be  necessary  in  many 
situations.   This  is  particularly  true  when  the  model  is 
nondecomposable.   For  example,  the  mapping  between  demand  and 
order  quantity  in  the  EOQ  model  cannot  be  used  independently 
unless  the  ordering  cost  and  holding  cost  are  also  present. 
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Therefore,  the  three  arcs  of  the  EOQ  model  are  highly  dependent 
and  can  be  combined. 

4 .  Model  level 

By  considering  each  model  stored  in  the  model  base  as  a 
mapping  between  input  and  output,  Liang's  approach  uses  a  node  to 
represent  a  set  of  data  attributes  and  an  arc  to  represent  a  set 
of  functions  that  can  be  used  to  convert  from  one  node  to 
another.   Since  a  model  is  composed  of  input,  output,  and  a  set 
of  functions  for  converting  input  to  output,  it  can  be 
represented  as  a  combination  of  two  nodes  and  one  arc.   For 
example,  the  EOQ  is  a  mapping  between  two  sets,  [Demand,  O_cost, 
H_cost]  and  [Quantity] . 

Because  each  model  in  the  model  base  is  considered  a  single 
mapping,  this  approach  allows  an  associated  cost  or  validity 
value  be  estimated  for  each  model.   It  is  important  when 
algorithms  and  heuristics  in  graph  theory  are  used  for  model 
integration  [Liang,  1987]. 

5.  Data  level 

On  top  of  the  hierarchy  is  a  relational  framework  of  models. 
Instead  of  adopting  artificial  intelligence  techniques,  Blanning 
(1982-86)  focuses  on  model  manipulations  including  join  and 
projection.   It  reflects  a  user-oriented  view  of  model  management 
—  the  user  obtains  the  desired  information  without  the  need  to 
see  all  the  details  of  calculation.   For  example,  the  EOQ  model 
is  considered  a  relation  composed  of  demand,  holding  cost, 
ordering  cost,  and  quantity. 

The  hierarchical  view  of  model  abstraction  indicates  that  a 
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model  integration  process  includes  the  following  steps: 

(1)  identify  the  desired  information; 

(2)  develop  a  master  plan  for  building  a  composite  model 
when  there  is  no  single  model  available  for  producing 
the  desired  information.   The  master  plan  determines  the 
sequence  by  which  a  set  of  models  should  be  executed; 

(3)  determine  the  model  structure  and  retrieve  the 
corresponding  model  specifications  according  to  the 
master  plan; 

(4)  evaluate  the  feasibility  of  the  master  plan  by  checking 
details  such  as  data  format  and  model  assumptions; 

(5)  combine  selected  programs  to  formulate  an  executable 
model,  if  the  master  plan  is  proven  feasible. 
Otherwise,  go  to  step  2  to  develop  another  plan. 

For  example,  if  the  inventory  holding  cost  is  not  a  constant 

but  determined  by  a  holding  cost  model  with  interest  expenses  and 

warehouse  operation  costs  as  its  inputs,  then  calculating  the 

economic  order  quantity  involves  an  integration  of  two  models: 

EOQ  and  the  holding  cost  model.   First,  the  MMS  finds  that  the 

table  (shown  on  the  top  of  Figure  2)  requested  by  the  user 

contains  information  from  more  than  one  model.   Then,  the  system 

develops  a  master  plan  for  executing  the  selected  models.   In 

this  example,  the  sequence  is  (1)  the  holding  cost  model,  and  (2) 

the  EOQ  model.   Based  on  the  master  plan,  the  structure  of  the 

composite  model  can  be  determined.   Figure  2  shows  the 

corresponding  representations  at  the  data  level,  model  level,  and 

structure  level.   Finally,  specifications  and  executable  programs 

can  be  activated  and  executed. 


INSERT  FIGURE  2 
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REASONING  IN  MODEL  INTEGRATION 

The  key  step  in  the  model  integration  process  is  the 
development  of  a  master  plan.   Unless  a  sequence  of  models  is 
found  capable  of  producing  the  desired  information,  there  is  no 
need  to  vthe/check^ integrity  constraint  or  data  format.   Therefore, 
each  state  in  the  modeling  process  can  be  represented  as  a  set  of 
data  attributes.   Each  basic  model  stored  in  the  model  base  is 
considered  an  operator  that  converts  one  state  into  another.   For 
instance,  the  EOQ  model  is  an  operator  that  converts  the  state, 
[Demand,  O_cost,  H_cost] ,  to  another  state,  [Quantity]. 

By  these  definitions,  all  available  information  constitutes 
the  initial  state  of  modeling  and  the  desired  information  is  the 
goal  state.   The  process  for  developing  a  master  plan  can  be 
described  as  a  process  by  which  operators  are  scheduled  to  convert 
the  initial  state  to  a  specified  goal  state  by  way  of  achieving  a 
set  of  subgoals  sequentially. 

Two  issues  are  crucial  to  developing  a  master  plan.   First, 
how  can  the  proper  candidate  models  in  the  model  base  be 
selected?   Second,  how  can  the  selected  models  be  scheduled 
efficiently?   In  this  section,  various  reasoning  strategies  and 
heuristics  for  improving  the  efficiency  of  model  scheduling  will 
be  discussed. 
REASONING  STRATEGIES 

Given  the  initial  state  and  the  desired  goal  state,  the 
first  step  to  developing  a  master  plan  is  to  choose  a  proper 
reasoning  strategy.   There  are  three  generic  strategies  that  may 
be  employed  for  model  integration:  forward  reasoning,  backward 
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reasoning,  and  bi-directional  reasoning.   Each  strategy  has  its 
advantages  and  drawbacks. 

The  forward  reasoning  strategy  requires  the  system  to  start 
from  the  initial  state  and  search  proper  candidates  based  on  the 
available  information.   Therefore,  it  is  also  called  data- 
directed  reasoning.   This  strategy  is  appropriate  when  the  goal 
state  is  complex  but  the  amount  of  initial  information  is 
relatively  small.   An  algorithm  that  applies  this  strategy  to 
model  integration  can  be  described  as  follows.   The  queue 
produced  by  this  algorithm  is  the  master  plan  for  converting  the 
initial  state,  INITIAL,  to  the  goal  state,  GOAL. 
REPEAT 

1.  Find  an  operator,  OP,  that  can  convert  a  state,  IN, 
to  another  state,  OUT,  where  IN  is  a  subset  of  the 
initial  state,  INITIAL; 

2.  Add  OP  to  a  queue  and  define  a  new  initial  state, 
NEWSTATE  =  (INITIAL  U  OUT)  -  IN; 

3.  Set  INITIAL  =  NEWSTATE 
UNTIL  GOALCT  INITIAL. 

The  backward  reasoning  strategy  is  goal-directed,  which 

requires  the  system  to  work  backward  from  the  goal  state  trying 

to  prove  it  from  the  facts  in  the  data  base.   It  works  well  when 

the  goal  state  contains  relatively  limited  amount  of  outputs  while 

the  initial  state  includes  a  large  amount  of  input  information. 

A  backward  model  integration  process  includes  the  following 

procedures.   The  resulting  stack  represents  a  master  plan. 

REPEAT 

1.  Find  an  operator,  OP,  that  converts  IN  to  OUT,  where 
OUTO  GOAL  #  0; 
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2.  Add  OP  to  a  stack  and  define  a  subgoal  state, 
SUBGOAL  =  (IN  U  GOAL)  -  OUT; 

3 .  Set  GOAL  =  SUBGOAL 
UNTIL  GOALC  INITIAL. 

Bi-directional  reasoning  uses  forward  and  backward  strategies 
simultaneously.   Its  major  advantage  is  that  it  decomposes  a 
problem  into  two  parts,  which  can  reduce  the  complexity  when  the 
number  of  nodes  at  each  step  grows  exponentially  with  the  number 
of  steps  that  have  been  taken  [Rich,  1983,  p. 60].   The  risk  for 
using  this  strategy  is  that  the  two  searches  may  pass  each  other, 
resulting  in  more  work  than  it  would  have  taken  for  either  one  of 
them. 

Because  the  amount  of  available  information  usually  is  much 
larger  than  the  amount  of  the  desired  information  in  most 
modeling  situations,  backward  reasoning  is  more  appropriate  for 
developing  a  master  plan.   The  other  two  strategies,  however,  may 
be  useful  to  explain  the  modeling  process  and  help  the  user 
understand  the  causal  relationship  between  inputs  and  outputs. 

Instead  of  defining  the  whole  set  of  desired  information  as 
the  goal  state,  a  modified  backward  reasoning  strategy,  called 
difference  elimination,  focuses  on  the  difference  between  the 
desired  state  and  the  initial  state.   Since  part  of  the  desired 
information  may  be  readily  available  from  the  data  base,  ignoring 
the  information  available  in  the  initial  state  can  simplify  the 
goal  state  and  hence  reduce  the  complexity  of  the  reasoning 
process.   In  this  case,  the  model  integration  process  can  be 
defined  as  a  process  by  which  the  difference  between  the  desired 
information  and  the  available  information  can  be  completely 
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eliminated.   Its  reasoning  process  is  as  follws: 
REPEAT 

1.  Set  the  goal  state  as  the  difference  between  the 
desired  information  and  the  available  information, 
GOAL  =  DESIRED  -  INITIAL; 

2.  Find  an  operator,  OP,  that  converts  IN  to  OUT,  where 
OUT  f)  GOAL  ^  0; 

3.  Add  OP  to  a  stack  and  define  a  subgoal,  SUBGOAL  = 
(IN  U  GOAL)  -  OUT; 

4.  Set  GOAL  =  SUBGOAL  -  INITIAL; 
UNTIL  GOAL  =  [ ] . 

HEURISTIC  SEARCH 

Although  the  difference  elimination  process  may  reduce  the 
complexity  of  the  goal  state,  it  still  relies  on  exhaustive 
search.   In  order  to  further  improve  the  efficiency  of  the 
search  process,  two  techniques  may  be  used:  macro-operators  and 
heuristic  evaluation  functions. 
1.  Macro-operators 

A  macro-operator  is  a  sequence  of  primitive  operators. 
Because  the  sequence  is  predetermined,  there  is  no  need  for 
search.   In  fact,  the  major  purpose  of  model  integration  is  to 
design  a  macro-operator  that  can  be  used  to  solve  a  particular 
problem.   Then,  how  can  we  use  macro-operators  to  improve  the 
efficiency  of  modeling?  A  macro-operator  is  both  the  result  of  a 
modeling  process  and  a  tool  for  modeling.   A  master  plan 
developed  for  solving  a  previous  problem  can  be  saved  as  a  macro- 
operator  for  later  use.   When  a  new  problem  includes  the 
previously  solved  problem  as  a  subproblem,  the  macro-operator  can 
be  retrieved  and  fitted  into  the  master  plan  directly.   From  this 
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perspective,  a  model  integration  process  is  also  a  learning 
process  by  which  macro-operators  are  learned. 

Using  macro-operators  involves  a  tradeoff  between  model 
storage  costs  and  modeling  costs.   On  the  one  hand,  the  extensive 
use  of  macro-operators  needs  a  large  amount  of  computer  memory  for 
storage.   On  the  other  hand,  lack  of  macro-operators  needs 
extensive  search  in  the  modeling  process.   Therefore,  an  important 
issue  here  is  to  what  extent  macro-operators  should  be  used. 

In  general,  there  are  two  criteria  for  determining  proper 
use  of  macro-operators:  functional  dependency  and  frequency  of 
use.   A  model  is  defined  functionally  dependent  on  another  model  if 
at  least  one  input  of  the  former  is  among  the  output  of  the 
latter.   If  there  exists  a  set  of  functionally  dependent  models, 
they  may  be  grouped  into  a  macro-operator. 

Determining  functional  dependency  is  also  important  for 
model  scheduling.   Model  B  must  be  scheduled  before  model  A  when 
model  A  is  functionally  dependent  on  model  B.   In  addition,  a  set 
of  functionally  dependent  models  may  result  in  a  cycle,  which 
traps  the  system  into  an  infinite  loop.   In  this  case,  mechanisms 
for  detecting  and  resolving  loops  must  be  applied. 

Another  factor  to  be  considered  is  frequency  of  use.   If  a 
particular  sequence  of  operators  is  used  frequently,  then  it  may 
be  appropriate  to  save  them  as  a  macro-operator.   Otherwise,  it 
may  be  unnecessary.   For  example,  if  the  holding  cost  model  and 
the  EOQ  model  shown  in  Figure  2  usually  are  used  together  in  an 
organization,  then  it  may  be  stored  as  a  macro-operator 
consisting  these  two  models  and  mapping  from  [Demand,  O_cost, 
W_cost,  I_cost]  to  [Quantity] . 
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2 .  Heuristic  Search 

In  addition  to  macro-operators,  heuristic  functions  may  be 
used  to  guide  a  search  process.   The  major  purpose  of  a  heuristic 
function  is  to  estimate  how  close  a  particular  state  is  to  the 
goal  state  so  that  the  system  can  select  the  best  search 
direction  accordingly.   In  general,  a  heuristic  evaluation 
function  provides  a  numerical  estimation  of  the  promise  of  a 
state,  which  may  depend  on  the  criteria  used  in  the  function,  the 
description  of  the  goal,  and  the  information  gathered  by  the 
search  up  to  that  point. 

Intuitively  there  are  several  criteria  that  may  be  used  to 
estimate  the  promise  of  a  state,  such  as  model  applicability, 
machine  capacity,  modeling  costs,  and  user  preference.   Model 
applicability  uses  context-dependent  measures  to  evaluate  the 
applicability  of  a  model  to  a  particular  problem.   For~ example, 
when  the  problem  is  identified  as  an  inventory  problem,  then  the 
EOQ  model  may  have  a  higher  value  compared  to  a  capital  budgeting 
model . 

Machine  capacity  or  modeling  cost  requires  the  heuristic 
evaluation  function  to  assess  the  anticipated  machine  capacity 
or  modeling  cost  for  each  state  and  then  select  the  best 
direction  to  further  explore.   It  focuses  on  developing  efficient 
or  cost-effective  models.   User  preference  is  a  subjective  measure 
of  model  applicability.   Its  goal  is  to  develop  a  model  most 
preferred  by  a  particular  user. 

A  major  drawback  of  these  criteria  is  that  it  is  difficult 
to  find  objective  measures.   For  instance,  it  is  unclear  what 
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should  be  measured  when  we  estimated  the  applicability  of  a 
model.   Therefore,  a  strictly  objective  criterion  is  desirable. 

One  feasible  criterion  is  the  distance  between  the  goal 
state  to  the  resulting  subgoal  state  after  applying  the  model. 
Since  each  state  represents  a  set  of  data  attributes,  the  distance 
between  two  states  can  be  defined  as  the  difference  between  the 
amounts  of  items  contained  in  those  two  states.   For  example,  the 
distance  between  state  A  and  state  B  in  Figure  3  is  1  because  the 
arc  reduces  the  number  of  items  in  the  goal  state  from  5  to  4 . 


INSERT  FIGURE  3 


Because  the  difference  elimination  process  is  basically  a 
backward  reasoning  process,  the  system  should  pursue  an  operator 
that  results  in  a  state  far  from  the  goal  state.   In  other 
words,  the  system  will  select  the  model  that  eliminates  the 
largest  amount  of  items.   This  allows  the  resulting  plan  to  have 
a  minimum  number  of  basic  models. 

By  taking  advantage  of  the  distance-based  heuristic 
evaluation  function,  the  reasoning  process  can  be  modified  as 
follows: 

REPEAT 

1.  Set  the  goal  state  as  the  difference  between  the 
desired  information  and  the  available  information, 
GOAL  =  DESIRED  -  INITIAL; 

2.  Find  all  operators,  OPS,  each  of  which  results  in  an 
OUT  state,  where  OUT  0  GOAL  ^  p; 

3.  Check  functional  dependencies  and  cyclicity  to 
exclude  the  operators  functionally  dependent  on 
others  and  remove  loops; 
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4.  Determine  the  resulting  subgoal  for  each  of  the 
remaining  operators  that  converts  IN  to  OUT, 

SUBGOAL  -  (IN  U  GOAL)  -  OUT ; 

5.  Calculate  the  distance  for  each  of  the  possible 
subgoals, 

Distance (GOAL, SUBGOAL)  =  Item (GOAL)  -  Item (SUBGOAL) ; 

6.  Select  the  operator  with  the  longest  distance,  OP, 
which  converts  IN  to  OUT; 

7.  Add  OP  to  a  stack  and  define  a  subgoal,  SUBGOAL  = 
(IN  U  GOAL)  -  OUT; 

8.  Set  GOAL  =  SUBGOAL  -  INITIAL; 
UNTIL  GOAL  =  [ ] . 


AN  EXAMPLE 

In  order  to  illustrate  how  the  difference  elimination 
process  develops  a  master  plan  for  model  integration,  a  prolog 
implementation  and  an  example  is  presented  in  this  section.   As 
listed  in  Appendix  1,  the  prolog  implementation  includes  the 
following  modules:  (1)  main  planning  module  for  defining  goals 
and  subgoals,  (2)  difference  determination  module  for  finding  the 
difference,  (3)  dependency  checking  module,  and  (4)  heuristic 
evaluation  function  for  selecting  the  best  operator. 

Assume  that  we  have  the  following  models  in  our  model  base: 

(1)  {ml,  [a,b,s,t],  [w,x,y]} 

(2)  {m2,  [c,e,r,t],[v,x]} 

(3)  (m3,  [c,d,r],  [v,s]} 

(4)  (m4,  [a,c,e],  [u] } 

(5)  {m5,  [d,f],  [r,y]} 

(6)  {m6,  [a,b,f],  [t]} 

Further  assume  that  the  data  base  contains  data  of 
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[a,b, c,d,e,f ]  and  the  decision  maker  needs  a  model  providing 
[u,v,w,x,y],  then  the  modeling  process  is  as  shown  in  Figure  4. 
The  system  first  applies  model  ml  to  reduce  the  difference  from 
[u,v,w,x,y]_  to  [u,v,s,t].   Then,  model  m3  and  m4  are  applied  to 
further  reduce  the  difference  to  [u,t,r]  and  [t,r]  respectively. 
Finally,  model  m5  and  m6  are  used  to  eliminate  the  difference, 
and  the  master  plan  is  developed  as  [m6,m5,m4 ,m3 ,ml] . 


INSERT  FIGURE  4 


CONCLUDING  REMARKS 


Developing  a  master  plan  is  a  key  step  to  model  integration. 
In  this  paper,  several  major  issues  have  been  discussed.   First, 
a  hierarchy  of  model  abstraction  has  been  described.   Then, 
various  reasoning  strategies  have  been  presented.   They  include 
forward,  backward,  bi-directional,  and  a  modified  backward 
strategy  called  difference  elimination.   Finally,  a  heuristic 
evaluation  function  for  improving  the  reasoning  efficiency  has 
been  developed. 

Since  reasoning  in  model  management  is  very  complex,  much 
further  research  is  required  before  a  practical  system  can  be 
developed.   Potential  research  directions  include  the  following. 
First,  how  can  various  levels  of  abstraction  be  integrated  into  a 
single  system?   Efficient  algorithms  must  be  developed  to  link 
representations  at  different  levels.   Second,  how  can  operators 
and  macro-operators  be  determined?   In  this  article,  this  issue 
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has  been  briefly  discussed  and  two  criteria  have  been  described: 
functional  dependency  and  frequency  of  use.   Detailed  discussions 
are  needed.   Third,  how  can  heuristic  evaluation  functions  be 
developed  and  evaluated.   A  measure  of  the  distance  between  two 
states  and  a  distance-based  heuristic  evaluation  function  are 
presented  in  this  article.   This,  however,  should  not  be  the  only 
way  to  do  it.   Therefore,  much  research  is  needed  to  explore 
alternative  measures  of  the  distance  between  states  and  evaluate 
various  measures  to  find  the  most  appropriate  one. 
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Appendix  1:  An  Implementation  of  the  Reasoning  Mechanism 
/*  Model  base  */ 

arc (ml, [a,b,s,t] , [w,x,y] ) . 

arc(m2, [c,e,r,t] , [v,x] ) . 
arc(m3, [c,d,r] , [v,s]) . 
arc(m4, [a,c,e] ,  [u] ) . 
arc(m5, [d,f] , [rfy]) . 
arc(m6, [a,b, f ] , [t] ) . 

/*  A  Prolog  Implementation   */ 

model : -write ( 'Output  attributes  =  '),  read (GOAL), 

write ('Input  Attributes  =  '),  read ( START ) ,nl, 

write ('**  Modeling  goal  =  '),  write (GOAL) ,nl,nl , 

model ing ( START , GOAL , START , ACTS ) , nl , 

write ('***  The  master  plan  is  to  execute  the  following'), 

nl, write ( 'models  sequentially:  '),nl,nl, 

write (ACTS) . 

model ing ( STARTSTATE , GOAL , STARTSTATE ,[]):- 
satisfy (STARTSTATE, GOAL) , ! . 

model ing ( STARTSTATE , GOAL , ENDSTATE , ACTS ) : - 
ma jordiff (STARTSTATE, GOAL, DIFF) , 
f indall_acts (STARTSTATE , DIFF , ALLACT) , 

write('All  possible  candidates  =  '),  write (ALLACT) ,nl, 
check_dependency (ALLACT, RESTACT) , 

write (' Independent  candidate  =  ' ) , write (RESTACT) , nl, 
heuristic (RESTACT, ACT ,V) , 

write ( 'Selected  action  by  a  heuristic  =  • ) , write (ACT) ,nl , 
subgoal (STARTSTATE , DIFF , ACT , START1 , SUBGOAL) , 
nl, write ('**  New  subgoal  =  ') , write (SUBGOAL) ,nl ,nl, 
model ing ( START 1 , SUBGOAL , _ , ACT1 ) , 
append (ACT1, ACT, ACTS) . 


satisfy (STARTSTATE, GOAL) :- 
subset (GOAL, STARTSTATE) . 

check_dependency ( [X] , [X] ) . 
check_dependency (ALLACT , RESTACT) : 

all_in (ALLACT, TIN) , 

del_prereq (ALLACT , TIN , RESTACT) 

all_in([],[]). 
all_in([a(ACT,V) ] ,TIN) :- 

arc (ACT, TIN) . 
all_in( [a(ACT,V) |REST] f TIN) :- 

arc (ACT, IN, OUT) , 

all_in(REST,TINl) , 

union(IN,TINl,TIN) . 
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del_prereq( [],_,[]). 

del_prereq( [a(ACT,V) |REST] , TIN, RESTACT) :- 

arc(ACT,IN,OUT) , 

subset (OUT, TIN) , 

del_prereq(REST, TIN, RESTACT) . 
del_prereq( [a(ACT,V) |REST] ,TIN, [a(ACT,V) |RESTACT] ) :- 

del_prereq (REST, TIN, RESTACT) . 

/*  Determining  major  difference  between  START  and  GOAL  */ 

majordiff (_, [],[]). 
majordiff (START, [X|R]  ,Z)  :- 

member (X, START) , 1 , 

majordiff (START, R,Z) . 
majordiff (START, [X|R] , [X|Z]) :- 

majordiff (START, R,Z) . 

/*  Submodels  required  for  bridging  the  difference  between 
the  starting  state  and  the  goal   */ 

findall_acts(STARTSTATE,DIFF,ALLACT) :- 
arc (ACT, IN, OUT) , 
intersection (OUT, DIFF,CONT) , 
CONT\=[], 

listlength(CONT,Ll)  , 
majordiff (STARTSTATE, IN, NEG) , 
listlength(NEG,L2)  , 
L  is  LI  -  L2 , 

assertz ( stack (a (ACT, L) ) ) , fail; 
assertz (stack(a (end, []))), 
collect (ALLACT) . 

collect (ALLACT) :- 

retract (stack(X) )  ,  !  , 
(X  ==  a (end, []),!,  ALLACT  =  []; 
ALLACT  =  [X | REST] , collect (REST) ) . 

heuristic( [a(ACT,V) ] , [ACT] ,V) . 
heuristic( [a(ACTl,Vl) |REST] , [ACT1] ,V1) :- 

heuristic (REST, [BestACT] ,VMax) , 

VI  >=  VMax. 
heuristic( [a(ACTl,Vl) |REST] , [BestACT] ,VMax) :- 

heuristic (REST, [BestACT] ,VMax) , 

VI  <  VMax. 

/*  finding  subgoals  */ 

subgoal (STARTSTATE, DIFF, [ACT] , START1 , SUBGOAL) :- 
arc (ACT, IN, OUT) , 
union ( STARTSTATE, OUT, START1) , 
union ( DIFF , IN , GOAL) , 
majordiff (START1, GOAL, SUBGOAL) . 
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/*  Utilities  */ 

append ( [ ] ,L,L)  . 

append ([A | X] ,Y, [A|Z]) :-  append (X, Y, Z) . 

member(X, [X|_]) . 

member (X, [_|  Y] ) : -member (X, Y) . 

subset ([A | X] ,Y) : -member (A, Y) , subset (X,Y) . 
subset([] ,Y) . 

intersection ( [ ] , X, [ ] ) . 
intersection ( [A| R] , Y, [A| Z] ) :- 

member (A, Y) , ! , intersection (R, Y, Z) . 
intersection ( [A|R] , Y,Z) : -intersection (R,  Y, Z) . 

listlength([] ,0) . 
listlength ( [H  |  R]  ,  L)  :  - 

listlength(R,Ll) , 

L  is  LI  +  1.  . 

union( [ ] ,X,X) . 

union([H|T] ,Y,Z) : -member (H,Y) , ! ,union(T, Y, Z) . 

union([H|T] ,Y, [H|Z]) : -union (T,Y, Z) . 
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Distance( A, B)  =  5-4  =  1 


Figure  3.  Distance  between  two  states 


utput    attributes    =    Cu,v,w,x,y3. 
nput    Attributes    =    C a , b , c , d , e , f 1 . 

*  Modeling    goal    =    [u,v,w,x,y] 

11    possible    candidates    =    CaCml  ,1  ),a(m2,0  ),a(m3,0  ),a(m4, 1  ),a(m5,l  )] 
ndependent    candidate    =    Ca(m1  ,1  )  ,  a(  m2  ,  0  )  ,  a(  m3  ,  0  )  ,  a(  m4  ,  1  ),a(m5,1  )3 
sleeted    action    by    a    heuristic    =    Cm1 3 

*  New    subgoal    =    [u,v,s,t] 

11    possible    candidates    =    Ca(m2,-1  ),a(m3,1  ),a(m4,1  ),a(m6,1  )3 
ndependent    candidate    =    Ca(m2,-1  ),a(m3,1  ),a(m4,1  )3 
elected    action    by    a    heuristic    =    Cm33 

*  New    subgoal    =    Cu,t,rJ 

11    possible    candidates    =    Ca(m4,1  ),a(m5,1  >,a(m6,1  )3 
ndependent    candidate    =    Ca(m4, I  ),a(m5,1  ),a(m6,  I  )] 
elected    action    by    a    heuristic    =    Cm43 

*  New    subgoal    =    Ct,r] 

11    possible    candidates    =    Ca(m5,1  ),a(m6,1  )3 
ndependent    candidate    =    Ca(m5,1  ),a(m6.1  )3 
sleeted    action    by    a    heuristic    =    Cm53 

*  New    subgoal    =    Ct3 

11    possible    candidates    =    Ca(m6,1  )3 
ndependent    candidate    =    Ca(m6,1 >3 
elected    action    by    a    heuristic    =    Cm63 

*  New    subgoal    =    nil 


**  The  master  plan  is  to  execute  the  following 
odels  sequentially: 

ti6  ,m5  ,m4  ,m3  ,m  I  3 


Figure  4.  A  Sample  Session 


r 


HECKMAN       |±| 
ilNDERY  INC.        |§| 

JUN95 

nd-To-PIeas^1  N.MANCHESTER 
INDIANA  46962     ' 


